home *** CD-ROM | disk | FTP | other *** search
- Path: news.erl.sbs.de!news
- From: Gerolf Wendland <wendland%hpp015%hpp001.mch2.scn.de@scn.de>
- Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
- Subject: Re: fastest code
- Date: Fri, 12 Apr 1996 10:11:35 +0200
- Organization: Siemens Business Services
- Message-ID: <316E1037.41C67EA6@scn.de>
- References: <316112A2.7D37@public.sta.net.cn> <4kgbmj$j3j@solutions.solon.com> <4kghs7$250@news1.mnsinc.com> <4kgu7g$n9a@solutions.solon.com> <4kjc9n$f7j@samba.rahul.net>
- NNTP-Posting-Host: 139.3.107.122
- Mime-Version: 1.0
- Content-Type: text/plain; charset=iso-8859-2
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.01 (X11; I; SunOS 4.1.3 sun4m)
-
- Whoever started this, he wrote:
- >
- > >>: >> for (i=0; i<16; i++)
- > >>: >> prom[i] = prom[i+i];
- > >
- > >>: HUH? the code as written has a clear effect, which is to shove all of
- > >>: the elements of an array over one. It certainly is an optimizer bug.
- ^^^^^^^^^^^^^^
- Really?
-
- Richard Krehbiel:
- >In fact, I wrote exactly this loop once whose purpose was to initialize the
- >parity bits in memory, but be non-destructive in case it was just a
- >restart and not a power-on.
-
- This seems to indicate that prom[i] are assigned a values that are never used.
- Maybe the optimizer has seen this. It should have issued a warning, which (the
- issueing) may have been prevented by not prom being the variable but by the
- somewhat anonymous locations prom[i] being the variables in question. The optimizer
- would have been even better if it had seen the fact that the loop is superflouos
- and had removed it as well.
-
- The volatile keyword is surely a good way to circumvent this problem.
-
- Gerolf Wendland
-